Partager via

Résoudre les problèmes de la pile de mise en réseau définie par le logiciel Windows Server

  • Article

Ce guide examine les erreurs et les scénarios d’échec courants du SDN (Software Defined Networking) et décrit un flux de travail de résolution des problèmes qui utilise les outils de diagnostic disponibles. Pour plus d’informations sur le système SDN, consultez Mise en réseau définie par logiciel (SDN).

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versions 21H2 et 20H2

Types d’erreurs

La liste suivante représente la classe de problèmes les plus souvent rencontrés avec la virtualisation de réseau Hyper-V (HNVv1) dans Windows Server 2012 R2 à partir de déploiements en production sur le marché et coïncide à bien des égards avec les mêmes types de problèmes que ceux rencontrés dans Windows Server 2016 HNVv2 avec la nouvelle pile SDN (Software Defined Network).

La plupart des erreurs peuvent être classées dans un petit ensemble de classes :

  • Configuration non valide ou non prise en charge

    Un utilisateur appelle l’API NorthBound de manière incorrecte ou avec une stratégie non valide.

  • Erreur dans l’application de stratégie

    La stratégie du contrôleur de réseau n’a pas été remise à un hôte Hyper-V, retardée ou non à jour sur tous les hôtes Hyper-V (par exemple, après une migration dynamique).

  • Dérive de configuration ou bogue logiciel

    Problèmes de chemin d’accès aux données entraînant des paquets supprimés.

  • Erreur externe liée au matériel/pilotes de carte réseau ou à l’infrastructure réseau sous-couche

    Déchargements de tâches incorrects (tels que VMQ) ou structure réseau mal configurée (par exemple, MTU)

    Ce guide de résolution des problèmes examine chacune de ces catégories d’erreurs et recommande les meilleures pratiques et les outils de diagnostic disponibles pour identifier et corriger l’erreur.

Outils de diagnostic

Avant de discuter des workflows de résolution des problèmes pour chacun de ces types d’erreurs, examinons les outils de diagnostic disponibles.

Pour utiliser les outils de diagnostic du contrôleur de réseau (chemin de contrôle), vous devez d’abord installer la RSAT-NetworkController fonctionnalité et importer le NetworkControllerDiagnostics module :

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Pour utiliser les outils de diagnostic HNV Diagnostics (chemin de données), vous devez importer le HNVDiagnostics module :

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnostics du contrôleur de réseau

Ces applets de commande sont documentées sur TechNet dans l’applet de commande Diagnostics du contrôleur de réseau. Elles permettent d’identifier les problèmes de cohérence de stratégie réseau dans le chemin de contrôle entre les nœuds du contrôleur de réseau et entre le contrôleur de réseau et les agents hôtes NC s’exécutant sur les hôtes Hyper-V.

Les Debug-ServiceFabricNodeStatus applets de commande doivent Get-NetworkControllerReplica être exécutées à partir de l’une des machines virtuelles du nœud contrôleur de réseau. Toutes les autres applets de commande diagnostic NC peuvent être exécutées à partir de n’importe quel hôte, qui dispose d’une connectivité au contrôleur de réseau et se trouve dans le groupe de sécurité de gestion du contrôleur de réseau (Kerberos) ou a accès au certificat X.509 pour la gestion du contrôleur de réseau.

Diagnostics de l’hôte Hyper-V

Ces applets de commande sont documentées sur TechNet dans l’applet de commande Diagnostics de virtualisation de réseau Hyper-V (HNV). Elles permettent d’identifier les problèmes dans le chemin des données entre les machines virtuelles clientes (Est/Ouest) et le trafic d’entrée via une adresse IP VIRTUELLE SLB (Nord/Sud).

Get-VMSwitchExternalPortIdGet-CustomerRouteTest-EncapOverheadSettings Get-PACAMappingGet-VMNetworkAdapterPortIdGet-ProviderAddressLes Debug-VirtualMachineQueueOperationtests locaux qui peuvent être exécutés à partir de n’importe quel hôte Hyper-V sont tous les tests locaux. Les autres applets de commande appellent des tests de chemin de données via le contrôleur de réseau et doivent donc accéder au contrôleur de réseau comme décrit ci-dessus.

GitHub

Le référentiel GitHub Microsoft/SDN a de nombreux exemples de scripts et flux de travail qui s’appuient sur ces applets de commande intégrées. En particulier, les scripts de diagnostic se trouvent dans le dossier Diagnostics . Aidez-nous à contribuer à ces scripts en soumettant des demandes de tirage.

Résolution des problèmes liés aux flux de travail et aux guides

[Hoster] Valider l’intégrité du système

Il existe une ressource incorporée nommée État de configuration dans plusieurs ressources du contrôleur de réseau. L’état de configuration fournit des informations sur l’intégrité du système, notamment la cohérence entre la configuration du contrôleur de réseau et l’état réel (en cours d’exécution) sur les hôtes Hyper-V.

Pour vérifier l’état de configuration, exécutez ce qui suit à partir de n’importe quel hôte Hyper-V ayant une connectivité au contrôleur de réseau.

Note

La valeur du NetworkController paramètre doit être le nom de domaine complet ou l’adresse IP en fonction du nom d’objet du certificat X.509 >créé pour le contrôleur de réseau.

Le Credential paramètre doit uniquement être spécifié si le contrôleur de réseau utilise l’authentification Kerberos (généralement dans les déploiements VMM). Les informations d’identification doivent être pour un utilisateur qui se trouve dans le groupe de sécurité de gestion du contrôleur de réseau.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Un exemple de message État de configuration s’affiche ci-dessous :

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Notes

Il existe un bogue dans le système où les ressources de l’interface réseau pour la carte réseau de la machine virtuelle SLB Mux Transit sont dans un état d’échec avec l’erreur « Commutateur virtuel - Hôte non connecté au contrôleur ». Cette erreur peut être ignorée en toute sécurité si la configuration IP dans la ressource de carte réseau de machine virtuelle est définie sur une adresse IP à partir du pool d’adresses IP du réseau logique de transit.

Il existe un deuxième bogue dans le système où les ressources de l’interface réseau pour les cartes réseau des machines virtuelles du fournisseur HNV de passerelle sont dans un état d’échec avec l’erreur « Commutateur virtuel - PortBlocked ». Cette erreur peut également être ignorée en toute sécurité si la configuration IP dans la ressource de carte réseau de machine virtuelle est définie sur nulle (par conception).

Le tableau ci-dessous montre la liste des codes d’erreur, des messages et des actions de suivi à effectuer en fonction de l’état de configuration observé.

Code Message Action
Unknown Erreur inconnue
HostUnreachable L’ordinateur hôte n’est pas accessible Vérifier la connectivité réseau de gestion entre le contrôleur de réseau et l’hôte
PAIpAddressExhausted Adresses IP pa épuisées Augmenter la taille du pool d’adresses IP du sous-réseau logique du fournisseur HNV
PAMacAddressExhausted Les adresses PA Mac sont épuisées Augmenter la plage de pool Mac
PAAddressConfigurationFailure Échec de l’aplomb des adresses PA à l’hôte Vérifier la connectivité réseau de gestion entre le contrôleur de réseau et l’hôte.
CertificateNotTrusted Le certificat n'est pas approuvé Corrigez les certificats utilisés pour la communication avec l’hôte.
CertificateNotAuthorized Certificat non autorisé Corrigez les certificats utilisés pour la communication avec l’hôte.
PolicyConfigurationFailureOnVfp Échec de la configuration des stratégies VFP Il s’agit d’un échec du runtime. Aucune solution de contournement définitive. Collecter les journaux.
PolicyConfigurationFailure Échec de l’envoi de stratégies aux hôtes, en raison d’échecs de communication ou d’autres erreurs dans le NetworkController. Pas d’actions définitives. Cela est dû à l’échec du traitement de l’état de l’objectif dans les modules du contrôleur de réseau. Collecter les journaux.
HostNotConnectedToController L’hôte n’est pas encore connecté au contrôleur de réseau Le profil de port n’est pas appliqué sur l’hôte ou l’hôte n’est pas accessible à partir du contrôleur de réseau. Vérifiez que la clé de Registre HostID corresponde à l’ID d’instance de la ressource serveur
MultipleVfpEnabledSwitches Il existe plusieurs commutateurs compatibles VFp sur l’hôte Supprimez l’un des commutateurs, car l’Agent hôte du contrôleur de réseau ne prend en charge qu’un seul commutateur virtuel avec l’extension VFP activée
PolicyConfigurationFailure Échec de l’envoi (push) de stratégies de réseau virtuel pour un VmNic en raison d’erreurs de certificat ou de connectivité Vérifiez si les certificats appropriés ont été déployés (le nom de l’objet du certificat doit correspondre au nom de domaine complet de l’hôte). Vérifiez également la connectivité de l’hôte avec le contrôleur de réseau
PolicyConfigurationFailure Échec de l’envoi (push) de stratégies de commutateur virtuel pour un VmNic en raison d’erreurs de certificat ou de connectivité Vérifiez si les certificats appropriés ont été déployés (le nom de l’objet du certificat doit correspondre au nom de domaine complet de l’hôte). Vérifiez également la connectivité de l’hôte avec le contrôleur de réseau
PolicyConfigurationFailure Échec de l’envoi (push) de stratégies de pare-feu pour un VmNic en raison d’erreurs de certificat ou de connectivité Vérifiez si les certificats appropriés ont été déployés (le nom de l’objet du certificat doit correspondre au nom de domaine complet de l’hôte). Vérifiez également la connectivité de l’hôte avec le contrôleur de réseau
DistributedRouterConfigurationFailure Échec de configuration des paramètres du routeur distribué sur la carte réseau virtuelle (vNic) hôte Erreur d’assemblage TCPIP. Peut nécessiter le nettoyage des cartes réseau virtuelles d’hôte PA et de récupération d’urgence sur le serveur sur lequel cette erreur a été signalée
DhcpAddressAllocationFailure Échec de l’allocation d’adresses DHCP pour une carte réseau de machine virtuelle Vérifiez si l’attribut d’adresse IP statique est configuré sur la ressource de carte réseau
CertificateNotTrusted
CertificateNotAuthorized		 Échec de la connexion au multiplexeur en raison d’erreurs de réseau ou de certificat Contrôlez le code numérique fourni dans le code du message d’erreur : il correspond au code d’erreur Winsock. Les erreurs de certificat sont granulaires : par exemple, le certificat ne peut pas être vérifié, le certificat n’est pas autorisé, etc.
HostUnreachable Le multiplexeur est non sain (cas courant, BGPRouter déconnecté) L’homologue BGP sur le commutateur RRAS (machine virtuelle BGP) ou Top-of-Rack (ToR) est inaccessible ou ne peut pas être correctement appairé. Vérifiez les paramètres BGP sur la ressource Multiplexeur d’équilibrage de charge logicielle et l’homologue BGP (machine virtuelle ToR ou RRAS).
HostNotConnectedToController L’agent hôte SLB n’est pas connecté Vérifiez que le service agent hôte SLB est en cours d’exécution ; Reportez-vous aux journaux de l’agent hôte SLB (en cours d’exécution automatique) pour les raisons pour lesquelles, si SLBM (NC) rejette le certificat présenté par l’état d’exécution de l’agent hôte affiche des informations nuancées
PortBlocked Le port VFP est bloqué, en raison de l’absence de stratégies de réseau virtuel/ACL Vérifiez s’il existe d’autres erreurs, ce qui peut entraîner le non-paramétrage des stratégies.
Surchargé Loadbalancer MUX est surchargé Problème de performances avec MUX
RoutePublicationFailure Loadbalancer MUX n’est pas connecté à un routeur BGP Vérifiez si MUX dispose d’une connectivité avec les routeurs BGP et si l’homologue BGP est correctement configuré
VirtualServerUnreachable Loadbalancer MUX n’est pas connecté au gestionnaire BGP Vérifier la connectivité entre SLBM et MUX
QosConfigurationFailure Échec de la configuration des stratégies QOS Vérifiez si une bande passante suffisante est disponible pour toutes les machines virtuelles si la réservation QOS est utilisée

Vérifier la connectivité réseau entre le contrôleur de réseau et l’hôte Hyper-V (service Agent hôte NC)

Exécutez la netstat commande ci-dessous pour vérifier qu’il existe trois ESTABLISHED connexions entre l’agent hôte nc et le ou les nœuds du contrôleur de réseau et un LISTENING socket sur l’hôte Hyper-V.

  • ÉCOUTE sur port TCP:6640 sur l’hôte Hyper-V (service agent d’hôte NC)
  • Deux connexions établies à partir de l’adresse IP de l’hôte Hyper-V sur le port 6640 à l’adresse IP du nœud NC sur des ports éphémères (> 32000)
  • Une connexion établie entre l’adresse IP de l’hôte Hyper-V sur le port éphémère et l’adresse IP REST du contrôleur de réseau sur le port 6640

Notes

Il ne peut y avoir deux connexions établies sur un hôte Hyper-V que s’il n’y a pas de machines virtuelles clientes déployées sur cet hôte particulier.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Vérifier les services de l’agent hôte

Le contrôleur de réseau communique avec deux services d’agent hôte sur les ordinateurs hôtes Hyper-V : agent hôte SLB et agent hôte NC. Il est possible qu’au moins l’un de ces deux services ne soit pas en cours d’exécution. Vérifiez leur état, puis redémarrez-les s’ils ne sont pas en cours d’exécution.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Vérifier l’intégrité du contrôleur de réseau

S’il n’y a pas trois ESTABLISHED connexions ou si le contrôleur de réseau ne répond pas, vérifiez que tous les nœuds et modules de service sont opérationnels à l’aide des applets de commande suivantes.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Les modules de service du contrôleur de réseau sont les suivants :

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Vérifiez que c’est ReplicaStatus et c’est Ready Ok.HealthState

Dans un déploiement de production se trouve avec un contrôleur de réseau à plusieurs nœuds, vous pouvez également vérifier le nœud sur lequel chaque service est principal et son état de réplica individuel.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Vérifiez que l’État du réplica est Prêt pour chaque service.

Rechercher les HostID et certificats correspondants entre le contrôleur de réseau et chaque hôte Hyper-V

Sur un hôte Hyper-V, exécutez les applets de commande suivantes pour vérifier que l’HOSTID correspond à l’ID d’instance d’une ressource de serveur sur le contrôleur de réseau

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Correction

Si vous utilisez des scripts SDNExpress ou un déploiement manuel, mettez à jour la clé HostId dans le Registre pour qu’elle corresponde à l’ID d’instance de la ressource serveur. Redémarrez l’agent hôte du contrôleur de réseau sur l’hôte Hyper-V (serveur physique) Si vous utilisez VMM, supprimez le serveur Hyper-V de VMM et supprimez la clé de Registre HostId. Ensuite, ajoutez à nouveau le serveur via VMM.

Vérifiez que les empreintes des certificats X.509 utilisés par l’hôte Hyper-V (le nom d’hôte sera le nom d’objet du certificat) pour la communication (SouthBound) entre l’hôte Hyper-V (service agent hôte NC) et les nœuds du contrôleur de réseau sont identiques. Vérifiez également que le certificat REST du contrôleur de réseau a le nom de CN=<FQDN or IP>l’objet .

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

Vous pouvez également vérifier les paramètres suivants de chaque certificat pour vous assurer que le nom de l’objet est ce qui est attendu (nom d’hôte ou nom de domaine complet REST NC), le certificat n’a pas encore expiré et que toutes les autorités de certification de la chaîne de certificats sont incluses dans l’autorité racine approuvée.

  • Nom de sujet
  • Date d'expiration
  • Approuvé par l’autorité racine

Si plusieurs certificats ont le même nom d’objet sur l’hôte Hyper-V, l’agent hôte du contrôleur de réseau choisit de façon aléatoire l’un d’entre eux à présenter au contrôleur de réseau. Cela peut ne pas correspondre à l’empreinte numérique de la ressource de serveur connue pour le contrôleur de réseau. Dans ce cas, supprimez l’un des certificats portant le même nom d’objet sur l’hôte Hyper-V, puis redémarrez le service Agent hôte du contrôleur de réseau. Si une connexion ne peut toujours pas être établie, supprimez l’autre certificat portant le même nom d’objet sur l’hôte Hyper-V et supprimez la ressource serveur correspondante dans VMM. Ensuite, recréez la ressource serveur dans VMM, qui générera un nouveau certificat X.509 et l’installera sur l’hôte Hyper-V.

Vérifier l’état de configuration SLB

L’état de configuration SLB peut être déterminé dans le cadre de la sortie de l’applet Debug-NetworkController de commande. Cette applet de commande génère également l’ensemble actuel de ressources du contrôleur de réseau dans des fichiers JSON, toutes les configurations IP de chaque hôte Hyper-V (serveur) et la stratégie de réseau local à partir des tables de base de données de l’agent hôte.

D’autres traces seront collectées par défaut. Pour ne pas collecter les traces, ajoutez le -IncludeTraces:$false paramètre.

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Note

L’emplacement de sortie par défaut est le <répertoire working_directory>\NCDiagnostics\. Le répertoire de sortie par défaut peut être modifié à l’aide du -OutputDirectory paramètre.

Les informations sur l’état de configuration SLB se trouvent dans le fichier diagnostics-slbstateResults.Json de ce répertoire.

Ce fichier JSON peut être divisé en les sections suivantes :

  • Infrastructure
    • SlbmVips : cette section répertorie l’adresse IP de l’adresse IP virtuelle du gestionnaire SLB, qui est utilisée par le contrôleur de réseau pour coordonner la configuration et l’intégrité entre les Muxes SLB et les agents hôtes SLB.
    • MuxState : cette section répertorie une valeur pour chaque Mux SLB déployé, indiquant l’état du mux
    • Configuration du routeur : cette section répertorie le numéro de système autonome (ASN) du routeur en amont (homologue BGP), l’adresse IP de transit et l’ID. Elle répertorie également l’ASN SLB Muxes et l’adresse IP de transit.
    • Informations sur l’hôte connecté : cette section répertorie l’adresse IP de gestion de tous les hôtes Hyper-V disponibles pour exécuter des charges de travail à charge équilibrée.
    • Plages d’adresses IP virtuelles : cette section répertorie les plages de pool d’adresses IP virtuelles publiques et privées. L’adresse IP VIRTUELLE SLBM sera incluse en tant qu’adresse IP allouée à partir de l’une de ces plages.
    • Mux Routes : cette section répertorie une valeur pour chaque Mux SLB déployé contenant toutes les annonces de routage pour ce mux particulier.
  • Client
    • VipConsolidatedState : cette section répertorie l’état de connectivité de chaque adresse IP virtuelle cliente, y compris le préfixe d’itinéraire publié, l’hôte Hyper-V et les points de terminaison DIP.

Notes

L’état SLB peut être déterminé directement à l’aide du script DumpSlbRestState disponible sur le référentiel GitHub SDN Microsoft.

Validation de la passerelle

À partir du contrôleur de réseau :

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

À partir d’une machine virtuelle de passerelle :

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

À partir du commutateur de rack (ToR) :

sh ip bgp summary (for 3rd party BGP Routers)

Routeur BGP Windows :

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

En plus de ces problèmes, d’après les problèmes que nous avons rencontrés jusqu’à présent (en particulier sur les déploiements basés sur SDNExpress), la raison la plus courante pour laquelle le compartiment de locataire n’est pas configuré sur les machines virtuelles GW semble être le fait que la capacité GW dans FabricConfig.psd1 est inférieure à ce que les utilisateurs essaient d’affecter aux connexions réseau (tunnels S2S) dans TenantConfig.psd1. Cela peut être vérifié facilement en comparant les sorties des applets de commande suivantes :

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hébergeur] Valider plan de données

Une fois que le contrôleur de réseau a été déployé, que des réseaux virtuels et des sous-réseaux de locataire ont été créés et que les machines virtuelles ont été attachées aux sous-réseaux virtuels, des tests supplémentaires au niveau de la structure peuvent être effectués par l’hébergeur pour vérifier la connectivité du locataire.

Vérifier la connectivité réseau logique du fournisseur HNV

Une fois que la première machine virtuelle invitée s’exécutant sur un hôte Hyper-V a été connectée à un réseau virtuel de locataire, le contrôleur de réseau affecte deux adresses IP du fournisseur HNV (adresses IP PA) à l’hôte Hyper-V. Ces adresses IP proviennent du pool d’adresses IP du réseau logique du fournisseur HNV et sont gérées par le contrôleur de réseau. Pour savoir quelles sont ces deux adresses IP HNV :

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Ces adresses IP du fournisseur HNV (PA) sont affectées à des cartes Ethernet créées dans un compartiment réseau TCPIP distinct et ont un nom d’adaptateur VLANX où X est le VLAN affecté au réseau logique du fournisseur HNV (transport).

La connectivité entre deux hôtes Hyper-V à l’aide du réseau logique du fournisseur HNV peut être effectuée par un ping avec un paramètre de compartiment supplémentaire (-c Y) où Y est le compartiment réseau TCPIP dans lequel les PAhostVNICs sont créés. Ce compartiment peut être déterminé en exécutant :

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Notes

Les adaptateurs de carte réseau virtuelle de l’hôte PA ne sont pas utilisés dans le chemin d’accès aux données et n’ont donc pas d’adresse IP affectée à l'« adaptateur vEthernet (PAhostVNic) ».

Par exemple, supposons que les hôtes Hyper-V 1 et 2 ont des adresses IP de fournisseur HNV (PA) de :

Ordinateur hôte Hyper-V Adresse IP PA 1 Adresse IP PA 2
Hôte 1 10.10.182.64 10.10.182.65
Hôte 2 10.10.182.66 10.10.182.67

nous pouvons effectuer un test ping entre les deux à l’aide de la commande suivante pour vérifier la connectivité réseau logique du fournisseur HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Correction

Si le test ping du fournisseur HNV ne fonctionne pas, vérifiez votre connectivité réseau physique, y compris la configuration du réseau local virtuel. Les cartes réseau physiques sur chaque hôte Hyper-V doivent être en mode jonction sans réseau local virtuel spécifique attribué. La carte réseau virtuelle de l’hôte de gestion doit être isolée sur le réseau local virtuel du réseau logique de gestion.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Vérifier la prise en charge des images MTU et jumbo sur le réseau logique du fournisseur HNV

Un autre problème courant dans le réseau logique du fournisseur HNV est que les ports réseau physiques et/ou la carte Ethernet n’ont pas suffisamment de MTU configuré pour gérer la surcharge à partir de l’encapsulation VXLAN (ou NVGRE).

Note

Certaines cartes Et pilotes Ethernet prennent en charge le nouveau *EncapOverhead mot clé qui sera automatiquement défini par l’Agent hôte du contrôleur de réseau sur la valeur 160. Cette valeur est ensuite ajoutée à la valeur du mot clé *JumboPacket dont la somme est utilisée comme MTU annoncée.

Par exemple, *EncapOverhead = 160 et *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Pour tester si le réseau logique du fournisseur HNV prend en charge la taille MTU supérieure de bout en bout, utilisez l’applet Test-LogicalNetworkSupportsJumboPacket de commande :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Correction

  • Ajustez la taille MTU sur les ports du commutateur physique pour qu’elle soit d’au moins 1674B (y compris l’en-tête Ethernet 14B et le code de fin)
  • Si votre carte de carte réseau ne prend pas en charge le mot clé EncapOverhead, ajustez le mot clé JumboPacket sur au moins 1674B

Vérifier la connectivité de la carte réseau de machine virtuelle du locataire

Chaque carte réseau de machine virtuelle affectée à une machine virtuelle invitée a un mappage CA-PA entre l’adresse de client privée (CA) et l’espace d’adressage du fournisseur (PA) HNV. Ces mappages sont conservés dans les tables de serveur OVSDB sur chaque hôte Hyper-V et peuvent être trouvés en exécutant l’applet de commande suivante.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Note

Si les mappages CA-PA attendus ne sont pas générés pour une machine virtuelle de locataire donnée, vérifiez les ressources de configuration ip et de carte réseau de la machine virtuelle sur le contrôleur de réseau à l’aide de l’applet Get-NetworkControllerNetworkInterface de commande. Vérifiez également les connexions établies entre l’agent hôte NC et les nœuds du contrôleur de réseau.

Avec ces informations, un test ping de machine virtuelle client peut maintenant être lancé par l’hôte à partir du contrôleur de réseau à l’aide de l’applet Test-VirtualNetworkConnection de commande.

Scénarios de résolution des problèmes spécifiques

Les sections suivantes fournissent des conseils pour des scénarios de résolution des problèmes spécifiques.

Aucune connectivité réseau entre deux machines virtuelles clientes

  1. [Locataire] Vérifiez que le Pare-feu Windows dans les machines virtuelles clientes ne bloque pas le trafic.
  2. [Locataire] Vérifiez que les adresses IP ont été affectées à la machine virtuelle du locataire en exécutant ipconfig.
  3. [Hoster] Exécutez Test-VirtualNetworkConnection à partir de l’hôte Hyper-V pour valider la connectivité entre les deux machines virtuelles clientes en question.

Note

Le VSID fait référence à l’ID de sous-réseau virtuel. Dans le cas de VXLAN, il s’agit de l’identificateur réseau VXLAN (VNI). Vous pouvez trouver cette valeur en exécutant l’applet de Get-PACAMapping commande.

Exemple

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Créez une autorité de certification ping entre « Green Web VM 1 » avec l’adresse IP SenderCA 192.168.1.4 sur l’hôte « sa18n30-2.sa18.nttest.microsoft.com » avec l’adresse IP Mgmt 10.127.132.153 à l’adresse IP ListenerCA 192.168.1.5, toutes deux attachées au sous-réseau virtuel (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Locataire] Vérifiez qu’aucune stratégie de pare-feu distribuée n’est spécifiée sur le sous-réseau virtuel ou les interfaces réseau de machine virtuelle qui bloquerait le trafic.

Interrogez l’API REST du contrôleur de réseau trouvée dans l’environnement de démonstration à l’adresse sa18n30nc dans le domaine sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Examinez la configuration IP et les sous-réseaux virtuels qui font référence à cette liste de contrôle d’accès

  1. [Hébergeur] Exécutez Get-ProviderAddress sur les deux hôtes Hyper-V hébergeant les deux machines virtuelles clientes en question, puis exécutez Test-LogicalNetworkConnection ou ping -c <compartment> à partir de l’hôte Hyper-V pour valider la connectivité sur le réseau logique du fournisseur HNV
  2. [Hébergeur] Assurez-vous que les paramètres de MTU sont corrects sur les hôtes Hyper-V et sur tous les périphériques commutateurs de couche 2 qui se trouvent entre les hôtes Hyper-V. Exécutez Test-EncapOverheadValue sur tous les hôtes Hyper-V en question. Vérifiez également si tous les commutateurs de couche 2 entre les hôtes ont une MTU définie sur au moins 1674 octets pour prendre en compte une surcharge maximale de 160 octets.
  3. [Hébergeur] Si les adresses IP PA ne sont pas présentes et/ou si la connectivité de l’autorité de certification est interrompue, vérifiez que la stratégie réseau a été reçue. Exécutez Get-PACAMapping pour voir si les règles d’encapsulation et les mappages CA-PA requis pour créer des réseaux virtuels en superposition sont correctement établis.
  4. [Hébergeur] Vérifiez que l’agent hôte du contrôleur de réseau est connecté au contrôleur de réseau. Pour cela, exécutez netstat -anp tcp |findstr 6640.
  5. [Hébergeur] Vérifiez que l’ID d’hôte dans HKLM/ correspond à l’ID d’instance des ressources serveur hébergeant les machines virtuelles clientes.
  6. [Hébergeur] Vérifiez que l’ID de profil de port correspond à l’ID d’instance des interfaces réseau de machine virtuelle des machines virtuelles clientes.

Journalisation, suivi et diagnostics avancés

Les sections suivantes fournissent des informations sur les diagnostics avancés, la journalisation et le suivi.

Journalisation centralisée du contrôleur de réseau

Le contrôleur de réseau peut collecter automatiquement les journaux du débogueur et les stocker dans un emplacement centralisé. La collecte des journaux peut être activée lorsque vous déployez le contrôleur de réseau pour la première fois ou à tout moment ultérieurement. Les journaux sont collectés à partir du contrôleur de réseau et des éléments réseau gérés par le contrôleur de réseau : machines hôtes, équilibreurs de charge logicielles (SLB) et machines de passerelle.

Ces journaux d’activité incluent les journaux de débogage pour le cluster du contrôleur de réseau, l’application du contrôleur de réseau, les journaux de passerelle, l’équilibrage de charge réseau, la mise en réseau virtuelle et le pare-feu distribué. Chaque fois qu’un nouvel hôte/SLB/passerelle est ajouté au contrôleur de réseau, la journalisation est démarrée sur ces machines. De même, lorsqu’un hôte/SLB/passerelle est supprimé du contrôleur de réseau, la journalisation est arrêtée sur ces machines.

Activation de la journalisation

La journalisation est automatiquement activée lorsque vous installez le cluster contrôleur de réseau à l’aide de l’applet de Install-NetworkControllerCluster commande. Par défaut, les journaux sont collectés localement sur les nœuds du contrôleur de réseau à l’emplacement %systemdrive%\SDNDiagnostics. Il est recommandé de modifier cet emplacement pour qu’il s’agit d’un partage de fichiers distant (pas local).

Les journaux du cluster du contrôleur de réseau sont stockés dans %programData%\Windows Fabric\log\Traces. Vous pouvez spécifier un emplacement centralisé pour la collecte de journaux avec le DiagnosticLogLocation paramètre avec la recommandation qu’il s’agit également d’un partage de fichiers distant.

Si vous souhaitez restreindre l’accès à cet emplacement, vous pouvez fournir les informations d’identification d’accès avec le LogLocationCredential paramètre. Si vous fournissez les informations d’identification pour accéder à l’emplacement du journal, vous devez également fournir le CredentialEncryptionCertificate paramètre, qui est utilisé pour chiffrer les informations d’identification stockées localement sur les nœuds du contrôleur de réseau.

Avec les paramètres par défaut, il est recommandé de disposer d’au moins 75 Go d’espace libre dans l’emplacement central et de 25 Go sur les nœuds locaux (si vous n’utilisez pas un emplacement central) pour un cluster contrôleur de réseau à trois nœuds.

Modifier les paramètres de journalisation

Vous pouvez modifier les paramètres de journalisation à tout moment à l’aide de l’applet de Set-NetworkControllerDiagnostic commande . Les paramètres suivants peuvent être modifiés :

  • Emplacement du journal centralisé.

    Vous pouvez modifier l’emplacement pour stocker tous les journaux, avec le DiagnosticLogLocation paramètre.

  • Informations d’identification pour accéder à l’emplacement du journal.

    Vous pouvez modifier les informations d’identification pour accéder à l’emplacement du journal, avec le LogLocationCredential paramètre.

  • Passer à la journalisation locale.

    Si vous avez fourni un emplacement centralisé pour stocker les journaux, vous pouvez revenir à la journalisation localement sur les nœuds du contrôleur de réseau avec le UseLocalLogLocation paramètre (non recommandé en raison d’un espace disque important).

  • Étendue de la journalisation.

    Par défaut, tous les journaux sont collectés. Vous pouvez modifier l’étendue pour collecter uniquement les journaux du cluster du contrôleur de réseau.

  • Niveau de journalisation.

    Le niveau de journalisation par défaut est Informational. Vous pouvez le remplacer par Erreur, Avertissement ou Détaillé.

  • Temps de vieillissement du journal.

    Les journaux sont stockés de manière circulaire. Vous disposez de trois jours de données de journalisation par défaut, que vous utilisiez la journalisation locale ou la journalisation centralisée. Vous pouvez modifier cette limite de temps avec le LogTimeLimitInDays paramètre.

  • Taille du vieillissement du journal.

    Par défaut, vous disposez d’un maximum de 75 Go de données de journalisation si vous utilisez la journalisation centralisée et de 25 Go si vous utilisez la journalisation locale. Vous pouvez modifier cette limite avec le LogSizeLimitInMBs paramètre.

Collecte des journaux et des traces

Les déploiements VMM utilisent la journalisation centralisée pour le contrôleur de réseau par défaut. L’emplacement de partage de fichiers pour ces journaux est spécifié lors du déploiement du modèle de service contrôleur de réseau.

Si aucun emplacement de fichier n’a été spécifié, la journalisation locale est utilisée sur chaque nœud du contrôleur de réseau avec les journaux enregistrés sous C :\Windows\tracing\SDNDiagnostics. Ces journaux sont enregistrés à l’aide de la hiérarchie suivante :

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Traces

Le contrôleur de réseau utilise (Azure) Service Fabric. Les journaux Service Fabric peuvent être requis lors de la résolution de certains problèmes. Ces journaux d’activité se trouvent sur chaque nœud du contrôleur de réseau sur C :\ProgramData\Microsoft\Service Fabric.

Si un utilisateur a exécuté l’applet Debug-NetworkController de commande, d’autres journaux seront disponibles sur chaque hôte Hyper-V, qui a été spécifié avec une ressource de serveur dans le contrôleur de réseau. Ces journaux (et traces si activés) sont conservés sous C :\NCDiagnostics.

Diagnostics SLB

Erreurs de structure SLBM (actions du fournisseur de services d’hébergement)

  1. Vérifiez que software Load Balancer Manager (SLBM) fonctionne et que les couches d’orchestration peuvent communiquer entre elles : SLBM -> SLB Mux et SLBM -> Agents hôtes SLB. Exécutez DumpSlbRestState à partir de n’importe quel nœud ayant accès au point de terminaison REST du contrôleur de réseau.
  2. Validez les SDNSLBMPerfCounters dans PerfMon sur l’une des machines virtuelles du nœud contrôleur de réseau (de préférence le nœud du contrôleur de réseau principal - Get-NetworkControllerReplica) :
    1. Le moteur Load Balancer (LB) est-il connecté à SLBM ? (SGBD LBEngine Configurations Total > 0)
    2. Le SLBM connaît-il au moins ses propres points de terminaison ? (Nombre total de points de terminaison VIP>= 2)
    3. Les hôtes Hyper-V (DIP) sont-ils connectés à SLBM ? (Clients HP connectés == serveurs num)
    4. SLBM est-il connecté à Muxes ? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Vérifiez que le routeur BGP configuré est correctement appairé avec l’expérience MUX SLB.
    1. Si vous utilisez RRAS avec l’accès à distance (c’est-à-dire, une machine virtuelle BGP) :
      1. Get-BgpPeer doit afficher connecté.
      2. Get-BgpRouteInformation doit afficher au moins un itinéraire pour l’adresse IP virtuelle auto-SGBD.
    2. Si vous utilisez un commutateur ToR (Top-of-Rack) physique en tant que pair BGP, consultez votre documentation :
      1. Par exemple : # show bgp instance
  4. Validez les compteurs SlbMuxPerfCounters et SLBMUX dans PerfMon sur la machine virtuelle SLB Mux.
  5. Vérifiez l’état de configuration et les plages d’adresses IP virtuelles dans la ressource Software Load Balancer Manager.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (vérifiez les plages d’adresses IP virtuelles dans les pools d’adresses IP et assurez-vous que l’adresse IP virtuelle SGBL (LoadBalanacerManagerIPAddress) et les adresses IP virtuelles côté locataire se trouvent dans ces plages)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Si l’une des vérifications ci-dessus échoue, l’état SLB du locataire sera également en mode d’échec.

Correction

En fonction des informations de diagnostic suivantes présentées, corrigez les éléments suivants :

  • Vérifier que les multiplexeurs SLB sont connectés
    • Résoudre les problèmes de certificat
    • Résoudre les problèmes de connectivité réseau
  • Vérifier que les informations de peering BGP sont correctement configurées
  • Vérifier que l’ID d’hôte dans le Registre correspond à l’ID d’instance de serveur dans la ressource du serveur (annexe de référence pour le code d’erreur HostNotConnected)
  • Collecter les journaux d’activité

Erreurs de locataire SLBM (actions de fournisseur de services d’hébergement et de locataire)

  1. [Hoster] Vérifiez Debug-NetworkControllerConfigurationState si des ressources LoadBalancer sont dans un état d’erreur. Essayez d’atténuer en suivant le tableau des éléments d’action dans l’annexe.
    1. Vérifiez qu’un point de terminaison d’adresse IP virtuelle est présent et que des itinéraires publicitaires sont disponibles.
    2. Vérifiez le nombre de points de terminaison DIP détectés pour le point de terminaison d’adresse IP virtuelle.
  2. [Locataire] Vérifiez que les ressources Load Balancer sont correctement spécifiées.
    1. Validez les points de terminaison DIP inscrits dans SLBM hébergent des machines virtuelles clientes, qui correspondent aux configurations IP du pool d’adresses principales LoadBalancer.
  3. [Hébergeur] Si les points de terminaison DIP ne sont pas découverts ou connectés :

    1. Vérification Debug-NetworkControllerConfigurationState

      Vérifiez que l’agent hôte NC et SLB est correctement connecté au coordinateur d’événements du contrôleur de réseau à l’aide netstat -anp tcp |findstr 6640)de .

    2. Archivez HostIdla nchostagent clé régulière du service (code d’erreur de référence HostNotConnected dans l’annexe) correspond à l’ID d’instance de la ressource de serveur correspondante (Get-NCServer |convertto-json -depth 8).

    3. Vérifiez que l’ID de profil de port pour le port de machine virtuelle correspond à l’ID d’instance de la ressource de carte réseau de machine virtuelle correspondante.

  4. [Fournisseur d’hébergement] Collectez les journaux.

Suivi SLB Mux

Les informations du software Load Balancer Muxes peuvent également être déterminées via observateur d'événements.

  1. Sélectionnez Afficher les journaux d’analyse et de débogage sous le menu Affichage de l’observateur d’événements.
  2. Accédez aux journaux>des applications et des services Microsoft>Windows>SlbMuxDriver>Trace dans l’Observateur d’événements.
  3. Cliquez dessus avec le bouton droit, puis sélectionnez Activer le journal.

Note

Nous vous recommandons de n’activer cette journalisation que pendant une courte période pendant que vous essayez de reproduire un problème.

Suivi VFP et vSwitch

À partir de n’importe quel hôte Hyper-V hébergeant une machine virtuelle invitée attachée à un réseau virtuel de locataire, vous pouvez collecter une trace VFP pour déterminer où se trouvent les problèmes.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes